-
Notifications
You must be signed in to change notification settings - Fork 1k
WIP: HashFromNode and VerifyDepTree methods #955
Conversation
* breadth-first traversal of directories, * while ignoring any directory named "vendor".
* caused by symbolic links
* want to only work with regular files, symlinks, and directories
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
CLAs look good, thanks! |
When I was developing in my own fork, I had to change the internal exports to point to my own fork's copy: I'm not certain why that particular commit is being shown as not included, but it's causing the build tests to fail, because the final commit is necessary to change the internal imports back to the original directories. |
Looking at the Details from I would like to force kick off a new build of |
Closed this PR, and will open a new one after I add a few more tests. |
yeah, this is one of those annoying things. the standard practice (or at least, what i do) is to just set up my own fork as an alternate remote, then work on it directly in the canonical location on GOPATH. IOW:
|
What does this do / why do we need it?
HashFromNode creates a cryptographic digest (using SHA-256) of the directory rooted at the specified pathname. This can be used to address #121.
VerifyDepTree verifies the dependency tree against a map of known dependencies, along with file system nodes that were not expected to be found.
What should your reviewer look out for in this PR?
Function signatures do not exactly match what @sdboyer requested.
Do you need help or clarification on anything?
Which issue(s) does this PR fix?
These functions were requested in order to address #121, however might serve to address #944 as well.